Instead of #Predicate<SwiftDataModel> you may also use any other (simpler) macro that's not #Rule.

Thank you for the suggestion!
I used "#ExampleMacro" as an example of Macro, referring NoMagicNumberRule.
Or, is it better to use an actual example?(e.g. #Preview?) 🤔

#ExampleMacro is great. The only reason I was suggesting another name is to keep the examples very simple and reduced down to the significant aspects. Otherwise, the name or its actual existence is not important as long as it's something different than #Rule to have a valid test case.

What comes to my mind now is that we should also test against #Rule without any arguments or more than one, the macro with a non-trailing closure, a return statement inside or more than one statement, ...

You can exclude these test cases from appearing in the documentation for simplicity by adding the argument excludeFromDocumentation: true. Only leave the ones you have now and skip the others as they are not helping users in understanding.

Nice suggestion, let me add the following tests.

• #Rule without any arguments
• #Rule with more than 1 argument
• #Rule with non-trailing closure
• #Rule with multiple trailing closure
• #Rule with a closure with the return statement
• #Rule with a closure with multiple statements.

So far, writing the code of the above test cases with the #Rule macro from the Tips Kit results in a compile error.
However, we added the tests for the following reasons. Do I understand correctly? 🤔

• To cover all the conditional branches introduced in this PR.
• To prepare for the possibility that the #Rule macro might support {no/multiple} {arguments/closures} in the future.

Yes, we want to make very sure that the rule only ignores the TipKit #Rule macro, not any other #Rule macro. To know for sure, the rule would need full type information. That's expensive, so we try to encode all the syntactic details we know about the macro in order to reduce false positives. That's not 100% even now, but close enough.

The compiler complains about these cases for TipKit's #Rule macro. There could be other #Rule macros which are not as strict. We still want to check them.

If you remove import TipKit and define your own #Rule macro, the compiler will be happy. That's what you need to imagining as a test setup (without specifying that explicitly).

Makes sense?

Yes! Thank you for explain it! I'm learning lot from you. 😄

To verify the correction mechanism, one test case is enough. We don't need to repeat all of them here again.